The present invention relates to systems and methods for registry driven semantic transformation of a document exchanged between businesses or applications. More particularly, it relates to systems and protocols for using one or more commonly accessible registries to transform electronic commerce documents among dissimilar interfaces, preferably XML documents.
Business-to-business (B2B) and application-to-application (A2A) electronic commerce are replacing former protocols for electronic data interchange (EDI). As businesses strive to improve their efficiency with B2B and A2A systems, a number of incompatible platforms and competing standards have emerged. One need that has been identified is to convert the documents from one system to another.
XML has become a widely used type of data because the rigid syntactic rules which must be applied to create inline markup make it relatively simple for computer programs to interpret and process. For example, a purchase order written in XML could be processed by an order entry software application that knows how to read the markup annotations that describe what is being purchased, who the purchaser is, and so forth. The growing acceptance of XML as an encoding scheme for documents has led to development of XML-ified application program interfaces for many legacy applications by enterprise adapter implementation (EAI) vendors.
EAI vendors bridge one system to the next, on an application-by-application basis. Interoperability is achieved by design, at design time. Connections between systems or applications are static. Implementation of new versions of applications requires modification of the static connections. Routing among applications is typically within an enterprise. Integration logic is developed on a point-to-point basis. Semantic logic is coded into EAI routines. Semantic logic and syntactic logic are mixed in the coding. The sending party or source of a document is responsible to ensure that what they send is exactly what the target or recipient has advertised to receive. There is no concept of modeling degrees of compatibility for an interface, as opposed to requiring perfect compatibility. This perfect compatibility is difficult to achieve, as it requires that all clients be updated with the latest versions of the services' interfaces and that interfaces be updated contemporaneously. Transformation components are difficult to reuse. No commonly accessible repository is provided to capture individual transformation preferences or to support transformation based on user profiles. The EAI vendor approach makes it difficult and costly to adapt transform routines from one pair of systems or applications to another.
FIG. 1 illustrates the EAI vendor approach, as applied to supplier processing of incoming purchase orders into four disparate systems. In this figure, incoming purchase orders originate from three sources 101, an electronic data interchange (EDI) buyer, and online store customer and an Open Application Group Business Object Document (OAG BOD)-compliant buyer. Each of the sources has a native interface 102 that produces a purchase order as input to the EAI infrastructure 103. The formats of the documents may include EDI, XML and OAG. Four target systems 106, include an SAP Financial system, an SAP MRP system, Biz IQ system and a Granger shipping system. The native formats of documents 105 accepted by these target systems include IDOC, BAPI, OAG and a custom application program interface (API). To connect the source and target, both syntactic and semantic differences need to be overcome. Point-to-point adapters 104 transform source documents into target documents on a pairwise basis. Even document transformations between systems utilizing the same syntax, such as OAG-to-OAG transformations, involved differing semantics, so an adapter is required. When a source or target system is updated, for instance if Oracle financials are substituted for SAP financials or an upgraded shipping system is installed, new adapters need to be written. In all likelihood, old and new adapters are both retained by the EAI infrastructure. As systems are updated, more and more adapters are subject to revision or replacement. A single transformation engine manages the transformation process and provides the transformation resources.
Accordingly, opportunities arise to devise methods and structures that commonly manage transformation of documents between dissimilar interfaces, that provide runtime interoperability and distributed execution of transformations.